Stop treating apostrophes as quote delimiters

split_command_args flips in_single_quote on every ', so ordinary text like O'Reilly is parsed as an unmatched quote and returned as an error. This parser is now used by recipe_slash_command::parse_recipe_args and skills::apply_skill_arguments, so slash-command recipes/skills that accept free-text arguments can fail on common apostrophes even when users are not trying to quote. Please only start single-quote mode when ' begins a quoted token (or otherwise support apostrophes inside unquoted words).

Useful? React with 👍 / 👎.

Reject required params passed as flags

parse_recipe_args currently treats both required and optional keys as valid --flag names, but the required-position tracking (required_idx) is only advanced by positional tokens. In a mixed call like --component Button old-lib, the positional token is incorrectly assigned back to component, which overwrites the flagged value and leaves from missing. This produces confusing "missing parameter" failures for otherwise reasonable input; either disallow --<required> entirely or mark required params as consumed when seen as flags.

Useful? React with 👍 / 👎.

Reserve names for all mapped recipe commands

The ACP command list only reserves names from recipes that successfully validate in commands_from_mappings, then it exposes same-named skills. Execution still checks raw recipe mappings first and returns a recipe error on invalid files, so users can be shown a skill command that is not actually invokable when an invalid mapped recipe with the same name exists. Reserve names from all configured recipe mappings (or fall back to skill resolution on recipe-validation errors) to keep discovery and execution consistent.

Useful? React with 👍 / 👎.

Accept '--' prefixed strings as flagged recipe values

The flag parser currently rejects any flag value whose token starts with --, so valid quoted inputs like /deploy service --args "--dry-run --force" are treated as Missing value for --args even though a value was provided. This blocks a common recipe pattern where a parameter is meant to carry downstream CLI options, because split_command_args strips quotes before this check and the value still begins with --.

Useful? React with 👍 / 👎.

Align /prompts input hint with actual argument parsing

The ACP command metadata advertises /prompts [--extension <name>], but command execution does not parse a --extension flag (it treats the first token as the raw extension name in handle_prompts_command). Following the published hint therefore fails with an "Extension '--extension' not found" style error instead of filtering prompts, so discovery metadata and runtime behavior diverge.

Useful? React with 👍 / 👎.

Use persisted cwd when publishing load_session commands

on_load_session builds the available-command list from args.cwd, but slash-skill execution later resolves skills from the session’s stored working directory (handle_skill_command reads it via session_manager.get_session). When those differ (for example clients that call load with a generic cwd like "~"), ACP advertises skills that are not actually runnable in that loaded session, causing /skill commands suggested by discovery to fail at runtime. Build the command update from goose_session.working_dir to keep discovery and execution aligned.

Useful? React with 👍 / 👎.

I think args.cwd is intentional here. on_load_session updates the persisted session working_dir before publishing commands:

  self.session_manager
      .update(&session_id)
      .working_dir(args.cwd.clone())
      .apply()
      .await?;

Slash-skill execution later reloads the session from session_manager, so it should resolve skills from that same updated cwd.

Honor single-quoted substrings inside tokens

The new single-quote guard only enters quote mode when current.is_empty(), so inputs like ENV='two words' cmd or --note='needs review' are tokenized at the internal space instead of being kept as one argument. This is a regression from the previous parser behavior and now affects every caller of split_command_args (notably stdio extension parsing plus recipe/skill slash-argument parsing), causing valid quoted values attached to env/flag prefixes to be misparsed or rejected.

Useful? React with 👍 / 👎.

I know this is pre-existing but I don't really see why we need to say to the model "This is now in your context"

I was wondering about this too! I'll remove it and check there are any difference

also pre-existing, but feels like this tracking should be inside Agent.execute_command after we parse

agree!

agree!

Should we have some structure to the args instead of a string and the REGEX and replace logic in the frontend?

It seems to me like if we had that structure - we could build a nice argument entry experience on the frontend

Good point on the UX! The reason we matched this shape is portability. Tt mirrors Claude Code and the agentskills.io spec, so skills move between tools without rewriting.

One option: keep the string as the source of truth (required, works everywhere), and let skills optionally declare structured arg metadata that the frontend uses when present. Authors who only care about portability do nothing extra; goose-native skills can opt in for the richer entry experience.

Preserve single-parameter positional args for optional-only recipes

When a recipe has no required parameters but does have a single optional parameter (for example a common args field), positional slash input now fails with Unexpected positional argument because only required.len() == 1 gets the greedy positional path. In resolve_command, this means /my-recipe some free text is rejected unless rewritten as --args ..., which is a behavior regression from the previous single-parameter flow and can break existing mapped recipe commands.

Useful? React with 👍 / 👎.

logic/rule for recipe params in slash command: required params take positionals, optional params use -- flags. We deliberately removed the args special-case

Disambiguate skill selection before inserting / command

This change makes skill picks insert /<name>, but the slash-command feed used by this popover can return duplicate names across Builtin/Recipe/Skill. In that case, selecting a Skill entry can execute a different command type because runtime resolution checks built-ins and recipes before skills, so the UI selection is no longer reliable for colliding names (e.g. a skill named prompt). Please dedupe/disambiguate command names (or preserve non-slash insertion when ambiguous) before emitting /<name>.

Useful? React with 👍 / 👎.

Skip non-token skill names in slash command export

commands_from_sources lowercases skill names but otherwise forwards them as slash command names, which allows entries containing spaces or other token-breaking characters. Slash parsing only takes the first token as the command, so a discovered skill like Code Review is advertised but cannot be invoked as /code review (it parses as command code). Filter/normalize to command-safe names before publishing these entries.

Useful? React with 👍 / 👎.